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Description 

[0001] The present invention relates to a method of 
transmitting data between application programs execut- 
ing on different devices interfaced to a local area network 
and, more particularly, to a method of transmitting data 
between application programs independent of any spe- 
cific protocol. 

[0002] Computerized local area networks (LAN's) are 
in widespread use for interconnecting many different 
computers and peripherals so as to allow users of the 
computers to communicate with one another and also to 
allow those users shared access to the peripherals. Re- 
cent developments in LAN's have seen the introduction 
of so-called "heterogeneous" LAN's, i.e., LAN's on which 
many different communication protocols are carried on 
a single Ethernet or Token-ring medium. Examples of 
different protocols are IPX, which is typically used by 
DOS-based PC's, UDP/IP, which is typically used by UN- 
IX-based workstations, and DDP, which is typically used 
by Macintosh computers. Each type of computer or work- 
station can be adapted through software to communicate 
using multiple different protocols. 
[0003] A peripheral also can include software, i.e., mul- 
tiple protocol stack modules, which allows the peripheral 
to communicate using multiple protocols in order to be 
shared on a heterogeneous LAN. A protocol stack is a 
software module that processes packets of data which 
are received from or are transmitted to the LAN using the 
corresponding protocol. The protocol stacks and the as- 
sociated lower-level software for network communica- 
tions are typically stored and executed on a network in- 
terface device which may be embedded in or attached 
to the peripheral. The network interface device serves 
as an interface which allows the peripheral to communi- 
cate with other network devices via the LAN. 
[0004] Networkdevices, i.e., network interface devices 
and computers which are interfaced to the LAN, also ex- 
ecute application programs. These programs execute at 
a level above the protocol stacks and can include, for 
example, print server programs, management programs 
which allow communication between a computer and a 
peripheral in order to configure or obtain status data from 
the peripheral, and other programs which may commu- 
nicate data between different devices interfaced to the 
LAN. Exemplary management programs include pro- 
grams that implement SNMP (Simple Network Manage- 
ment Protocol) and CM IP (Common Management Infor- 
mation Protocol). More than one such management pro- 
gram may be executing on a single network device at the 
same time. 

[0005] US-A-5301 303 discloses a network component 
in the form of a multiple channel concentrator which pro- 
vides a number of physical communication channels for 
connection to LANs having different physical media such 
as twisted pair, coaxial or fibre optic and/or communica- 
tion protocols such as Ethernet, fibre distribution data 
interface (FDDI), token bus and token ring. A number of 



media distribution modules effective to implement a par- 
ticular protocol and having ports for connection to a spe- 
cific medium provide a connection between the particular 
medium and the connector. Thus, a network may be 
5 linked to the concentrator via a media distribution module 
to establish connection to another network. Bridging and 
rooting modules within the concentrator allows commu- 
nication between different channels and between net- 
works having different protocols, either converting one 
10 protocol to another or filtering transmissions. 

[0006] EP-A-0288713 discloses an input/output con- 
troller coupling a host computer to a device in an infor- 
mation processing system. Each input/output device has 
an associated control table for relating the device to pro- 
's gram instructions stored in the controller defining com- 
munications protocol. When data is to be transferred be- 
tween the input/output device and the host computer, 
information in the control table is used to call program 
instructions to impose the correct communications pro- 
20 tocol to govern the transfer of the data to the input/output 
device. 

[0007] In a conventional approach, an application pro- 
gram communicates with a protocol stack via an appli- 
cation programming interface (API) and uses the protocol 

25 stack to perform communications services. An applica- 
tion program must use different APIs to interface with 
each different protocol stack. This means that the appli- 
cation program must be aware of the particular network 
environment, i.e., the protocol in use, and the specific 

30 network API to be used. 

[0008] The conventional approach leads to many dif- 
ficulties. If an application program must support multiple 
network protocols, duplicated effort is required for the 
application software to handle the different APIs. For ex- 

35 ample, an SNMP program must include software code 
to communicate with an IPX protocol stack and a DDP 
protocol stack, in addition to code to communicate with 
a UDP protocol stack. Moreover, a CM IP program or any 
other application will also require the extra code for com- 

40 municating with different protocol stacks. As a result, ap- 
plication programs that are designed to support multiple 
protocols using the conventional approach require a 
more complex design, have a longer development time, 
have less portability, and have a higher maintenance cost 

45 than application programs which support a single proto- 
col. 

[0009] Accordingly, a way is needed for application 
programs to communicate with application programs on 
other networkdevices independent of a specific protocol. 
50 [0010] The above need is addressed by the present 
invention in which data is transmitted between applica- 
tion programs executing on different devices independ- 
ent of a specific protocol. 

[001 1 ] According to the present invention, there is pro- 
55 vided a method of delivering a data packet received from 
a first application program executing on a first device 
which is interfaced to a Local Area Network to a second 
application program executing on a second device which 
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is interfaced to the Local Area Network, the method com- 
prising the steps of: 

receiving a protocol independent data packet from 
the first - application program, together with data 
identifying the first application program and a desti- 
nation I D identifying the second application program; 
determining which protocols are available for use on 
the Local Area Network; and 

assigning a respective access line to each of the 
protocols available for use on the Local Area Net- 
work, 

said method being characterised by the steps of: 



selecting, from the available protocols, the pro- 
tocol assigned to the access line having the least 
traffic; 

determining protocol specific information which 
includes a type of protocol header and address 
information in the header corresponding to data 
identifying the first application program and the 
protocol selected in said selecting step; 
forming atransmission packet including the data 
packet, the destination ID, and the determined 
protocol specific information; and 
transmitting the transmission packet to the sec- 
ond application program via the Local Area Net- 
work. 

[0012] By virtue of this arrangement, a data packet 
which is received from one application program without 
any data specifying a protocol can be transmitted to an- 
other application program based only on information 
identifying the source and destination programs received 
from the one application program. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0013] 

Figure 1 is a diagram of a local area network. 
Figure 2 is a diagram showing the software architec- 
ture used for communication between application 
programs according to an exemplary embodiment 
of the present invention. 

Figure 3 is a diagram showing the functional rela- 
tionships between software modules executing on a 
computer and a network interface device. 
Figure 4 is a functional block diagram of a network 
expansion board for interfacing a printer to a local 
area network. 

Figure 5 illustrates software modules that may be 
stored in memory on the network expansion board. 
Figure 6 is a flow diagram showing process steps 
for transmitting a data packet between a first appli- 
cation program executing on a first network device 
and a second application program executing on a 
second network device. 



DESCRIPTION OF AN EXEMPLARY EMBODIMENT 
[1 . System Overview] 

[0014] Figure 1 is an illustration of a heterogeneous 
network system including several different types of com- 
puters and several different peripherals to which the com- 
puters can share access. The present invention can also 
be used with devices connected to a homogenous net- 
work, i.e., a network in which every device uses the same 
protocol. 

[0015] In Figure 1 , LAN 1 0 is depicted as an Ethernet 
medium which has a bus-type architecture, but a Token- 
ring medium having a ring-type architecture can be used 
as well. Connected to LAN 1 0 are a PC 20 which serves 
as a system administrator's computer, a PC 30 which 
serves as a print server for printers 85 and 95, a Macin- 
tosh computer 40, a UNIX workstation 50, and a gener- 
alized workstation 60 having a control unit 61 and a dis- 
play 62. A fileserver 70 allows shared access to a network 
disk 75. A network expansion board (NEB) 100 allows 
shared access to a printer 1 05, and a network expansion 
device (NED) 1 1 0 allows shared access to a printer 1 1 5. 
In addition, a network interface board (NIB) 120 allows 
shared access to a copier 1 35 via a multiple device con- 
troller (MDC) 130. 

[001 6] The present invention relates to communication 
between application programs executing on different net- 
work devices. A preferred form of the present invention 
is described below in the context of communication be- 
tween PC 20 and NEB 1 00. However, the present inven- 
tion is applicable to computers and embedded network 
devices in general. Accordingly, the present invention 
can be applied to communication between other comput- 
ers such as Macintosh computer 40, UNIX workstation 
50, generalized workstation 60 and other network inter- 
face devices such as NED 1 1 0 (an example of which is 
described in copending U.S. Patent Application S.N. 
08/489, 1 1 6 filed on June 9, 1 995, and entitled "Outputting 
a Network Device Log File") and NIB 120 (an example 



Figures 7A and 7B show examples of protocol map- 
ping tables created by protocol independent inter- 
faces. 

Figures 8A and 8B show examples of access I D map- 
5 ping tables created by protocol independent inter- 

faces. 

Figures 9A and 9B show examples of protocol ad- 
dress mapping tables created by protocol independ- 
ent interfaces. 

10 Figures 10A through 10C show examples of trans- 

mission packet formats for use with different proto- 
cols. 

Figure 1 1 is a flow diagram showing process steps 
for receiving a data packet transmitted from a first 
15 application program executing on one network de- 
vice to a second application program executing on 
another network device. 
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of which is described in U.S. Patent Application S.N. 
08/409,034 (corresponding to European application no. 
96301 994.8), filed on March 23, 1 995, and entitled "Net- 
work Interface Board For Digital Copier", which is as- 
signed to the assignee of the present invention). 
[0017] The present invention also can be applied to 
communication between application programs executing 
on different computers that have the capacity to use mul- 
tiple protocols. Moreover, the present invention is not lim- 
ited to network applications, but instead can be used for 
devices having a direct connection through any bidirec- 
tional interface, e.g., a shared memory, a SCSI interface, 
an RS-1284 parallel interface, or the like. 

[2. Software Architecture] 

[001 8] Figure 2 shows the software architecture of pro- 
gram modules executing on a network device such as 
NEB 1 00. Similar software executes on a computer such 
as PC 20. A network interface driver 210 is the lowest 
level of software which interfaces with LAN 1 0 and han- 
dles sending and receiving of packets on LAN 1 0 by add- 
ing or stripping off packet frame headers. Network inter- 
face driver 210 includes a media-type specific compo- 
nent which is designed for either an Ethernet or a Token- 
ring network medium and includes a plurality of logical 
boards for respectively processing packets having differ- 
ent frame types. A multiplexer software module 220 
serves as a multiplexer which routes packets between 
network interface driver 210 and one or more protocol 
stacks. Each protocol stack receives packets that use 
the corresponding protocol, determines what needs to 
be done with the packets, and routes the packets to the 
appropriate application programs for servicing. The pre- 
ferred embodiment supports three protocol stacks: IPX 
stack 230, UDP stack 231, and DDP stack 232. All of the 
protocol stacks might not be loaded on a particular de- 
vice. Further, additional stacks for other protocols may 
be included. In the preferred embodiment, network inter- 
face driver 210, multiplexer software module 220, and 
protocol stacks 230 - 232 conform to the Open Data-Link 
Interface (ODI) specification described in "Open Data- 
Link Interface Developer's Guide for DOS Workstation 
Protocol Stacks", Version 1 .10, Released by Novell, Inc., 
March 18, 1992. 

[0019] A protocol independent interface (Pll) 250 
serves as an interface between protocol stacks 230 - 232 
and management application programs such as an 
SNMP application program 260 and a CMIP application 
program 270. Pll 250 "listens" for data packets ad- 
dressed to particular sockets, i.e., addresses, and ac- 
cepts those packets from the protocol stacks 230 - 232 
for processing and forwarding to the application pro- 
grams. Since SNMP program 260 and CMIP program 
270 are executing on an embedded device, i.e., NEB 
1 00, those programs are "agent" programs. An agent pro- 
gram collects and stores data regarding the network in- 
terface device, i.e., NEB 100, and the peripheral, i.e., 



printer 105, and responds to commands sent using the 
associated network management protocol, e.g., SNMP 
or CMIP, from a related "manager" program executing 
on a computer. 

5 [0020] For example, the following predetermined ad- 
dresses are used in the preferred embodiment for receiv- 
ing data packets using the SNMP network management 
protocol: (1) for IPX, "socket" 900F H and 901 0 H (agent 
socket and trap socket, respectively), (2) for UDP, "port" 

10 1 60 H and 1 61 H , and (3) for DDP, a unique name "SNMP 
Agent" and "SNMP Trap Handler" and "socket" 8 H and 
9 H (agent socket and trap socket, respectively). Data 
packets that are not addressed to a socket used by a 
management program are routed to other application 

15 programs. For example, a PSERVER program 245 re- 
ceives data packets via an API 240. Other application 
programs, including other management programs, can 
also be included. 

[0021] Figure 3 is a diagram showing the functional 

20 relationship between manager programs executing on 
PC 20 and agent programs executing on NEB 100. As 
shown in Figure 3, PC 20 includes a protocol independent 
interface (Pll) 255, an SNMP manager 265, and a CMIP 
manager 275. During an initialization process described 

25 below, Pll 255 assigns a unique identifier referred to as 
an access ID to each management program. The access 
ID may be, for example, the MAC address of the device 
together with an additional number to uniquely identify 
each of SNMP manager 265 and CMIP manager 265. 

30 Reference numerals 281 , 282, and 283 designate logical 
channels used by different respective protocols, such as 
IPX, UDP, and/or DDP. Pll 255 assigns an identifier re- 
ferred to as a "logical access line" to each of the protocols, 
i.e., logical channels 281 283, during initialization. Bydy- 

35 namically assigning access IDs and logical access lines, 
the Pll can be readily adapted to support later-developed 
protocols without affecting the existing functionality. 
[0022] Pll 250 in NEB 1 00 likewise assigns an access 
ID to each of SNMP agent 260 and CMIP agent 270 and 

40 assigns a logical access line to each of the protocols. 
However, since the access IDs and logical access lines 
are specific to the Pll that assigns them, the access IDs 
and logical access lines assigned by Pll 250 in NEB 100 
can differ from those assigned by Pll 255 in PC 20. For 

45 example, as shown in Figure 3, SNMP manager 265 has 
access ID #2 in PC 20, but the corresponding agent in 
NEB 100, i.e., SNMP agent 260, has access ID #1. Sim- 
ilarly, as shown in Figure 3, Pll 250 assigns logical access 
line #1 to logical channel 281 , which may correspond to 

50 an IPXprotocol,forexample, while Pll 255 assigns logical 
access line #3 to the same logical. channel/protocol. 
[0023] Pll 250 and Pll 255 perform identical interface 
functions. However, there are some differences in imple- 
mentation due to the different platforms on which these 

55 software modules execute. For example, since Pll 250 
executes on an embedded device, it is implemented as 
a TSR (terminate and stay resident) routine. On the other 
hand, SNMP manager 265 is a Windows based applica- 
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tion and PI I 255 is implemented as a Windows-based 
DLL (Dynamic Link Library). Other differences are indi- 
cated in the description below where appropriate. 

[3. NEB Architecture] 

[0024] Figure 4 is a functional block diagram of NEB 
1 00. Broadly speaking, NEB 1 00 is an interactive network 
circuit board which couples printer 105 to LAN 10, making 
printer 105 a responsive and interactive network mem- 
ber. NEB 100 includes a shared memory SRAM 200 
which is used for bidirectional communications between 
NEB 100 and printer 105. Printer 105 includes a printer 
interface card 220 (not shown) having a microprocessor 
225 (not shown) that reads data from and writes data to 
SRAM 200. Printer 105 also includes a printer engine 
250 (not shown) connected to printer interface card 220. 
[0025] NEB 100 receives print data, status requests, 
and control commands from LAN 1 0, transmits print data, 
status requests, and control commands to printer 1 05 for 
execution, and transmits status information back to LAN 
1 0. Thus, NEB 1 00 can perform not only RPRINTER re- 
mote printer services and PSERVER print server func- 
tionalities, but can also offer to network members what- 
ever status and control features are available from the 
peripheral interface. 

[0026] Power for all circuits is supplied to NEB 100 
from a +5V power source 398. Power is provided from 
power source 398 to power converter 396 which provides 
-9V power to a transceiver 390 and to power converter 
397 which provides +1 2V power to a flash EPROM 350 
for "flashing" (i.e., reprogramming of the EPROM). Net- 
work and network interface control logic 340 is preferably 
a single 144-pin application specific integrated circuit 
(ASIC) that includes a network controller 330 and inter- 
face control logic 320. Network controller 330 is an NCR 
macro-cell compatible with a National DP83902A "ST- 
NIC" Ethernetcontroller,thedetailsofwhichcan be found 
in National Semiconductor's Local Area Networks Dat- 
abook , National Semiconductor p/n 400055, National 
Semiconductor, 1993. Network controller 330 is de- 
signed to interface with CSMA/CA-type (carrier sense 
multiple access with collision detection) local area net- 
works. 

[0027] Network controller 330 connects with RJ-45 
connector 385 directly and with coaxial connector 395 
through transceiver 390, which is preferably a National 
Semiconductor DP8392 coaxial transceiver interface, 
the details of which can also be found in National's Local 
Area Networks Databook . Network controller 330 is also 
coupled to an 8KB SRAM 380 that is used as an input/ 
output packet buffer for Ethernet data. This memory 
should preferably have an access time of about 70 ns or 
less. 

[0028] I nterf ace control logic 320 provides an interface 
between network controller 330, microprocessor 300, 
and memory devices EPROM 350 and DRAM 360. In- 
terface control logic 320 also interfaces with non-volatile 



random access memory (NVRAM) 370, which is a 256 
byte serial electrically erasable/programmable memory 
used for initialization data storage during power cycling 
of printer 1 05. Network and printer configuration param- 
5 eters are written into NVRAM 370 when printer 105 is 
first installed onto the network to allow NEB software to 
recover the installation parameters after printer power 
has been cycled off and on. 

[0029] Interface control logic 320 also couples with se- 

10 rial port connector 325, which comprises a receive data 
pin 326 and a transmit data pin 327 that can respectively 
receive and transmit serial data streams for debugging 
purposes. Interface control Iogic320 senses data present 
at the receive data line and samples the serial bits at 

15 regular intervals. 

[0030] The central controller of NEB 1 00 is microproc- 
essor 300, which is preferably an Intel 80C1 88EA-20 8- 
bit processor, the details of which can be found in the 
80C186EA/80188EA User's Manual, Intel p/n 

20 270950-001 , Intel Corp. This processor is an 8-bit proc- 
essor with direct memory access (DMA), interrupts, tim- 
ers, and a DRAM refresh control. Other microprocessors, 
such as an AMD 80C1 88-20 8-bit microprocessor, might 
alternatively be used. 256 KB flash EPROM 350 and 512 

25 KB DRAM 360 are coupled to microprocessor 300 via 
interface control logic 320, while 32 KB SRAM 200 (which 
is shared with printer interface card 220) is coupled with 
microprocessor 300 via arbiter control logic 400. A 40 
MHz, 50 ppm crystal oscillator 310 provides microproc- 

30 essor 300 with a clock signal that is wholly separate from 
and asynchronous with the clock signal provided to mi- 
croprocessor 225 on printer interface card 220. 
[0031] Microprocessor 300 executes instructions in 
flash EPROM 350, which stores control firmware and 

35 printing application software. After power-on self-test 
(POST), code from EPROM 350 is selectively moved to 
the higherperformance512KB DRAM 360, which should 
preferably have an access time of about 80 ns, for actual 
execution. 

40 [0032] All communication between NEB 1 00 and print- 
er interface card 220 is executed via 32 KB shared SRAM 
200. Arbiter control logic 400, preferably a single 1 00-pin 
ASIC, arbitrates between the two-byte-wide memory ac- 
cesses of printer interface microprocessor 225 and the 

45 single-byte-wide memory accesses of NEB microproc- 
essor 300, each of which is completely independent of 
the other. 

[0033] Generally speaking, the 8-bit data bus of micro- 
processor 300 on board NEB 100 communicates with 

50 bus control logic 41 0, while the 32-bit data bus of micro- 
processor 225 on board printer interface card 220 com- 
municates with bus control logic 420. Memory accesses 
from each bus are routed to shared memory arbiter 430, 
which determines which bus has priority and permits the 

55 bus with priority to access SRAM 200 via SRAM interface 
440. Interrupt control register 450 is also accessed 
through shared memory arbiter 430, to allow one micro- 
processor to interrupt the other. 
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[0034] All software modules executed by microproc- 
essor 300 are stored in flash EPROM 350. Those mod- 
ules that are needed are selectively loaded from EPROM 
350 into DRAM 360 and are executed from DRAM. This 
permits flexible configuration of NEB 1 00 by selection of 
which modules are to be loaded. 

[0035] Figure 5 illustrates an example of blocks of 
code, or software modules, that are stored in flash 
EPROM 350. The PI I module contains process steps for 
providing the required functions of a protocol independ- 
ent interface, as described in more detail below. The XPL 
module provides a standardized interface between print- 
er 105 and NEB 100. MLID (Multi Link Interface Driver) 
serves as network interface driver 21 0 and is a piece of 
Novell code (Media Support Module, or MSM) linked to- 
gether with a piece of customized code (Hardware Sup- 
port Module, or HSM) that is the lowest level of network 
connection, while LSL (Link Support-Layer) serves as 
multiplexer software module 220 and is a piece of Novell 
code that acts as a multiplexer between the low level 
MLID and the several protocol stacks above it. CNETX 
is customized code that turns local DOS-like function 
calls into network function calls, providing file functions 
like OPEN, READ, WRITE, and CLOSE. 
[0036] The PRETASK module is responsible for iden- 
tifying what frame types are associated with the various 
possible protocol stacks. Because NEB 100 supports 
multiple protocol stacks, this module exists as long as 
NEB 1 00 is running. 

[0037] Novell's IPX/SPX protocol stack is contained in 
flash EPROM 350, and is supported by SAP, or Service 
Advertising Protocol. SAP is a Novell concept that allows 
devices to register themselves into the file server's bind- 
ery, which lists active and inactive network entities. Be- 
cause print servers are a special kind of bindery item, 
SAP registers NEB 1 00 via CPSOCKET, and if NEB 1 00 
is configured as a print server, SAP also registers the 
print server with the NetWare bindery. 
[0038] CPSERVER is a custom implementation of a 
Novell print server application. This module provides self- 
generated print banners, user notification of completion 
and exception status, and transmission of print data and 
status commands to the printer. This differs from the 
Novell print server in that CPSERVER is dedicated to 
driving the local printer (i.e., printer 105 in which NEB 
100 is installed) and cannot drive any remote RPRINT- 
ERs. This program owns the print data lines for the du- 
ration of a print job. CRPRINTER is a custom implemen- 
tation of a Novell RPRINTER print application. This mod- 
ule is a slave application that is sent data by a Novell 
print server application elsewhere on LAN 1 0. 
[0039] The TCP/IP protocol stack has User Datagram 
Protocol (UDP), Reverse Address Resolution Protocol 
(RARP) and BootP support within. INTERRUPT is the 
interrupt handler for the TCP/IP task, while TIMERTICK 
is the timer tick for UNIX TCP/IP network tasks. LPRINT- 
SERVER is the TCP/IP print server application, and also 
owns the print data lines for the duration of a print job. 



DDP is the module for implementing a Datagram Delivery 
Protocol (DDP) which is used, for example, for commu- 
nications with a Macintosh computer. 
[0040] The CPSOCKET program runs for all protocol 
5 stacks. The program responds to requests for Connec- 
tion, requests for data download, or requests for services 
from remote utilities, and provides status and control to 
other tasks via interprocess communication. Because 
CPSOCKET typically owns the status and control lines 
10 between NEB 1 00 and printer 1 05, it is the only task that 
has the ability to obtain printer status via the status lines. 
CPSOCKET is responsible for the network connection 
and packet contents between the Novell-oriented status 
and control utilities (CPNET or the corresponding Win- 
's dows version of client-based software utilities), or be- 
tween the UNIX-oriented status and control utilities 
(CPUTIL). 

[0041] MONITOR is a customized multi-tasking mon- 
itor which performs task creation, task destruction and 
20 microprocessor dispatch. MONITOR also has memory 
management sub-modules MEMGET and MEMFREE. 
RESIDENT is a block of routines that provides generic 
services such as read and write to flash EPROM 350, 
FLASH code, ROM based debugger, hardware timer tick 
25 and other basic features. POST is a power-on self-test 
module that checks the integrity of NEB hardware and 
software at power-up. 

[0042] Also stored in EPROM 350 is a network identi- 
fication file (NIF) data block which stores board-invariant 
30 information, which is unique for every network board, 
hardware configuration data, board revision number and 
the like, as well as changeable information such as soft- 
ware version number. The information in the NIF data 
block is used to ensure that flash EPROM 350 is not 
35 reprogrammed with an incompatible firmware image. 
[0043] Specifically, EPROM 350 stores "board" infor- 
mation such as model number, firmware level, and board 
revision number, as well as "network" information such 
as Media Access Control (MAC) address, which is unique 
40 for every network board, board name, network frame 
type, primary file server identification, queues serviced, 
network protocol, sampling frequency, PSERVER name, 
zone-name, and the like. 



[0044] Figure 6 is a flow diagram showing process 
steps for implementing a protocol independent method 
of transmitting a data packet from a first application pro- 

50 gram executing on a first device which is interfaced to a 
LAN to a second application program executing on a sec- 
ond device which is interfaced to the LAN. Briefly, ac- 
cording to Figure 6, a protocol independent interface (Pll) 
program is initialized which determines which protocols 

55 are available for use, assigns an access line to each pro- 
tocol that is available for use, assigns an access ID to 
the first application program, and creates mapping infor- 
mation that indicates a one-to-one correspondence be- 
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tween an access ID/access line pair and a block of pro- 
tocol specific information which includes a protocol head- 
er having predetermined address data. This one-to-one 
mapping can be done by using a mapping table, as in 
the preferred form described below, or by implementing 
a data structure that carries the mapping information. A 
data packet is sent to the PI I program together with the 
access ID of the first application program and a destina- 
tion ID for the second application program, and one of 
the available protocols is selected to transmit the data 
packet. A block of protocol specific information is re- 
trieved from the mapping table based on the access ID 
of the first application program and the access line cor- 
responding to the selected protocol, and a transmission 
packet is formed which includes the data packet, the des- 
tination ID, and the retrieved block of protocol specific 
information. The transmission packet is then transmitted 
via the LAN. 

[0045] More specifically, the process steps of Figure 
6 show transmission of a data packet from SNMP man- 
ager 265 on PC 20 to SNMP agent 260 on NEB 100. The 
function of PI I 250 to transmit a data packet from SNMP 
agent 260 to SNMP manager 265 is the same, with the 
only differences being the differences in implementation 
discussed herein. In step S601 , SNMP manager 265 ex- 
ecutes an initialization command to initialize Pll 255. This 
command must be executed prior to execution of any 
other Pll commands and need only be performed once. 
As mentioned above, Pll 255 is implemented in Windows 
as a DLL. Accordingly, in response to the initialization 
command, the necessary operations are performed to 
enable SNMP manager 265 to execute other Pll com- 
mands using the DLL. In contrast, initialization of Pll 250 
by SNMP agent 260 in NEB 1 00 returns a table of entry 
points that SNMP agent 260 uses to call other Pll rou- 
tines. 

[0046] Pll 255 then determines which protocols are 
available for use by PC 20. In the preferred embodiment, 
where PC 20 is operating in a Windows or DOS Novell- 
ODI environment, function calls which obtain an indica- 
tion of the presence or absence of each protocol stack 
are issued in a round-robin manner to determine which 
protocol stacks are available. Alternatively, commands 
to execute respective initialization routines for each pro- 
tocol stack can be issued in round-robin fashion. If an 
initialization routine fails, the failure is interpreted to in- 
dicate that the protocol stack is not available at that in- 
stant. In the embedded platform, i.e., for Pll 250 on NEB 
100, the pretask module has information regarding the 
available protocol stacks and that information is obtained 
and used by Pll 250. 

[0047] Afterdetermining which protocols are available, 
Pll 255 opens a socket for each available protocol de- 
pending on the type of protocol, and sets up a protocol 
mapping table. This table has a one-to-one correspond- 
ence between an access line and a type of protocol stack. 
As noted above, the mapping table is one of many pos- 
sible implementations. For example, the protocol map- 



ping also can be implemented as a bit map or some other 
data structure. The key is that there is a way of indicating 
a one-to-one correspondence between the access line 
and protocol stack. The mapping table used in the pre- 

5 ferred embodiment is formed by assigning an access line 
to each available protocol and storing data indicating the 
access line assigned to each protocol in a section of 
memory reserved for use by Pll 255. Figure 7A is an 
example of a protocol mapping table that may be created 

10 by Pll 255 when UDP, IPX, and DDP protocols are avail- 
able, using the exemplary access line assignments 
shown in Figure 3. 

[0048] After initialization of Pll 255 in step S601 , flow 
proceeds to step S602 in which an Open command is 

15 executed by SNMP manager 265 to open a session. This 
command returns an access ID for a management pro- 
gram to use to identify itself, e.g., access ID #2 for SNMP 
manager 265. Pll 255 stores data indicating the relation- 
ship between access IDs and management programs in 

20 the section of memory reserved for use by PI 1 255. Figure 
8A is an example of an access ID mapping table set up 
by Pll 255 to indicate the relationship between access 
IDs and management programs. As with the protocol 
mapping table discussed above, the mapping between 

25 access IDs and application programs is capable of many 
implementations other than a mapping table, e.g., a bit 
map or other data structure. The data in Figure 8A cor- 
responds to the exemplary assignment of access IDs 
shown in Figure 3. The access IDs are shown as XXXX1 

30 or XXXX2, where XXXX represents the MAC address of 
PC 20 and the 1 and 2 indicate CMIP manager 275 and 
SNMP manager 265, respectively. The purpose of an 
access ID is to uniquely identify different entities that uti- 
lize the Pll, for example, CMIP manager 275 and SNMP 

35 manager 265. 

[0049] Flow next advances to step S603 in which a 
data packet is sent to Pll 255 from SNMP manager 265. 
The packet is sent by providing a pointer to the packet's 
location in memory, together with the access ID for SNMP 

40 manager 265 and a destination ID for the packet's des- 
tination. Since no information indicating a transmission 
protocol is required for the packet, the packet is protocol 
independent and a single interface is provided between 
an application program and all protocol stacks. The des- 

45 tination ID of the corresponding agent, e.g., SNMP agent 
260 corresponding to SNMP manager 265, is determined 
in the preferred embodiment by performing a locate_ 
agent function before data is sent to an agent. For ex- 
ample, in the case where Novell Netware is used, this 

50 function is performed by looking in a bindery in fileserver 
70 to determine devices which are registered in the bind- 
ery, e.g., by using IPX's SAP function, and which may 
have compatible agents. Communication with those de- 
vices then takes place to obtain a destination ID for the 

55 agent. In a UNIX environment, the locate_agent function 
is performed by using predetermined host tables. In an 
AppleTalk environment, an agent is located using a 
unique name. Any other technique can also be used 
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which allows the manager program to obtain a destina- 
tion ID for an agent program. 

[0050] After the packet is sent to PI 1 255, flow proceeds 
to step S604 in which a protocol is selected to transmit 
the data packet. If only one protocol is available, that 
protocol will be used. In the preferred embodiment, a 
protocol is selected by using a default or preferred pro- 
tocol, if available. For example, UDP is the preferred pro- 
tocol for transmitting data between SNMP manager 265 
and SNMP agent 260. If the preferred protocol is not 
available, then the first available protocol is used. How- 
ever, there are many alternative variations for selecting 
a protocol to use. For example, a protocol can be selected 
randomly or the first available protocol can be used. Also, 
the protocol having the least traffic can be used. For ex- 
ample, in a Novell environment, library functions such as 
GetLocalTarget can return an estimate of the time re- 
quired to deliver a 576-byte packet to a designated des- 
tination. These functions provide information related to 
network traffic using the corresponding protocol. A call 
to those functions can be used to obtain information in- 
dicating which protocol has the least traffic. Further, PI I 
255 can store a counter for each protocol (or access line) 
and can select the one that PI I 255 has used the fewest 
times, or PI I 255 can store a time at which each protocol 
(or access line) was last used and can select the one that 
was used least recently. 

[0051] After selecting a protocol to transmit the data 
packet, flow advances to step S605 in which PI I 255 re- 
trieves a block of protocol specific information, i.e., a pro- 
tocol specific address, from a protocol address mapping 
table stored in memory. The information is retrieved 
based on the access ID of the transmitting program and 
the access line corresponding to the selected protocol. 
If the mapping table does not have an entry for the Access 
ID/Access line pair, for example, if the packet is the first 
packet transmitted by Pll 255 for a particular manager 
using a particular protocol, an entry is added to the table. 
[0052] Figure 9A illustrates an example of a protocol 
address mapping table created by Pll 255. There is a 
one-to-one correspondence between an Access ID/ Ac- 
cess line pair and a protocol specific address. Reference 
numeral 901 designates a column of Access ID/Access 
line pairs. Reference numeral 902 represents a column 
of protocol specific addresses that each include a proto- 
col header of a type indicated in column 903. Each pro- 
tocol header has a different format. The various protocol 
header formats are described in detail below with respect 
to Figures 1 0A - 1 0C. However, regardless of type, each 
protocol header includes some type of address data, e.g. , 
a socket for an IPX header, a port for a UDP header, and 
asocketand name for a DDP header. Reference numeral 
904 indicates a column showing the specific address data 
included in each protocol header. 

[0053] The address data indicated in column 904 rep- 
resents standard address data that is defined for use by 
a particular manager and protocol. For example, the 
SNMP protocol (access ID XXXX2 in Figures 8A and 9A) 



uses the following address data: (1) for IPX, "socket" 
900F H and 901 0 H (agent socket and trap socket, respec- 
tively), (2) for UDP, "port" 160 H and 1 61 H , and (3) for 
DDP, a unique name "SNMP Agent" and "SNMP Trap 
5 Handler" and "socket" 8 H and 9 H (agent socket and trap 
socket, respectively). Likewise, the CM IP protocol uses 
specific address data such as a CM IP port for UDP, a 
CM IP socket for IPX, and a CM IP name and socket for 
DDP. An SNMP protocol packet and a CMIP protocol 
10 packet may have the same header type, but each header 
will include different specific address data. For example, 
the protocol specific addresses shown in rows 1 and 4 
of Figure 9A each have a UDP-type header, but each 
header contains different address data as shown in col- 
's umn 904. If SNMP manager 265 has access ID XXXX2, 
as indicated in Figure 8A, and the preferred protocol UDP 
is being used and has access line #1, as indicated in 
Figure 7A, then the protocol specific address in the fourth 
row of Figure 9A will be retrieved by Pll 255, which cor- 
20 responds to Access ID/Access line pair XXXX2/1 . 

[0054] If the present invention is used with application 
programs that do not have predefined sockets, standard 
identification values must be defined for those application 
programs and the PI Is used with both manager and agent 
25 programs must be programmed to used those standard 
identification values. 

[0055] As mentioned above, each type of protocol 
header has a different format, as described with respect 
to Figures 10A - 10C. Figure 10A shows a format for a 

30 local network frame (or "transmission packet") 1000 
when the frame is transmitted using a UDP protocol. In 
this case, network frame 1000 includes a local network 
header 1 01 0 and a local network trailer 1 01 5. It also in- 
cludes an IP header 1021, a UDP header 1020, and data 

35 1 030. As shown in Figure 10A, UDP header 1020 in- 
cludes fields for asource port, a destination port, a length, 
and a checksum. Figure 1 0B shows a format for network 
frame 1000 when the frame is transmitted using an IPX 
protocol. In that case, network frame 1000 does not in- 

^0 dude IP header 1021 and includes an IPX header 1025 
in lieu of UDP header 1020. IPX header 1025 includes 
fields for a checksum, a packet length, a transport control 
value, a packet type, a destination network, a destination 
node, a destination socket, a source network, a source 

45 node, and a source socket. Lastly, Figure 10C shows a 
format for network frame 1 000 when the frame is trans- 
mitted using a DDP protocol. In this case, the network 
frame also lacks IP header 1021 and includes a DDP 
header 1028 instead of either UDP header 1020 or IPX 

50 header 1 025. DDP header 1 028 includes fields contain- 
ing, 00, Hop, a datagram length, a datagram checksum, 
a destination network, a source network, a destination 
node ID, asource node ID, a destination socket number, 
a source socket number, and a DDP type. 

55 [0056] Referring again to Figure 6, after retrieving the 
protocol specific information, flow proceeds to step S606 
in which Pll 255 forms a transmission packet which is 
specific to the selected protocol, i.e., a network frame 
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1000 having one of the formats shown in Figures 10A - 
10C. The transmission frame is formed using the desti- 
nation information provided by SNMP manager 265 and 
the information retrieved from the protocol address map- 
ping table in step S605. Further, data 1030 is the data 
being sent by SNMP manager 265. 
[0057] After forming transmission packet 1000, flow 
proceeds to step S607 in which transmission packet 1 000 
is transmitted to the destination application program via 
LAN 10. 

[0058] Figure 1 1 is a flow diagram showing process 
steps for receiving transmission packet 1000 at NEB 1 00. 
In step S1 1 01 , SNMP agent 260 issues a command to 
initialize Pll 250. Pll 250 must be initialized before it can 
receive data from LAN 1 0 or SNMP agent 260. As men- 
tioned above, SNMP agent 260 obtains a table of entry 
points into routines of Pll 250 upon initialization, and Pll 
250 determines which protocols are available by obtain- 
ing information from the PRETASK software module. Fig- 
ure 7B shows an exemplary protocol table that is set up 
and stored by Pll 250 when UDP, IPX, and DDP protocols 
are available and access lines are assigned as shown in 
Figure 3. 

[0059] Flow then advances to step S1102 in which 
SNMP agent 260 issues a Pll open command to obtain 
an access ID. Figure 8B shows an exemplary mapping 
of access IDs to management agents that is set up and 
stored by Pll 250, based on the exemplary assignment 
of access IDs shown in Figure 3. In Figure 8B, YYYY 
represents the MAC address of NEB 100. SNMP agent 
260 is a passive entity which responds when SNMP man- 
ager 265 requests information but does not initiate com- 
munication. Accordingly, SNMP agent 260 listens for 
packets on all protocols that are available, i.e., packets 
addressed to any socket defined for SNMP use. There- 
fore, once an access ID is provided for an agent, e.g., 
SNMP agent 260, a mapping table is created with access 
ID/access line pair entries for every access line. Figure 
9A shows an exemplary protocol address mapping table 
for Pll 250 based on the exemplary data in Figures 7A 
and 8A. 

[0060] Flow then advances to step S1 103 in which a 
transmission packet is received from LAN 10. Referring 
to Figure 2, transmission packet 1000 is received from 
LAN 10 by network interface driver 21 0 and is routed to 
multiplexer software module 220 and then to one of pro- 
tocol stacks 230 - 232. For example, when transmission 
packet 1 000 represents data sent from SNMP manager 
265 to SNMP agent 260 using the preferred UDP proto- 
col, transmission packet 1000 is routed to UDP protocol 
stack 231 . Pll 250 listens for packets addressed to spe- 
cific sockets, e.g., sockets defined for use by manage- 
ment programs, and ignores all others. Since transmis- 
sion packet 1000 is addressed to one of the sockets to 
which Pll 250 listens, Pll 250 will receive the packet. 
[0061] Flow then advances to step S1104 in which Pll 
250 obtains an Access I D/Access line pair based on pro- 
tocol specific information 1020 in transmission packet 



1000 by referring to the protocol address mapping table 
for Pll 250 shown in Figure 9A. For exemplary transmis- 
sion packet 1000, Access ID/Access line pair YYYY1/2 
will be retrieved from row 2 in Figure 9A. 

5 [0062] Flow then advances to step S1 1 05 in which data 
1 030 is passed to the appropriate management program. 
This is done by referring to the access ID mapping infor- 
mation for Pll 250, which is discussed above with refer- 
ence to Figure 8B. For example, Access ID YYYY1 cor- 

10 responds to SNMP agent 260, so data 1 030 of transmis- 
sion packet 1000 is passed to SNMP agent 260. 
[0063] Although an example has been described for 
transmitting data from a manager in PC 20 to an agent 
in NEB 1 00, the same process is applicable for transmit- 

15 ting data from NEB 100 to PC 20. Moreover, as discussed 
above, the present invention is not limited to transmission 
of data between management application programs and 
is not limited to network transmissions. Accordingly, while 
the preferred embodiment of the invention has been de- 

20 scribed, it is to be understood that the invention is not 
limited to the above-described embodiments and that 
various changes and modifications may be made by 
those of ordinary skill in the art without departing from 
the scope of the invention. 

25 

Claims 

1 . A method of delivering a data packet received from 
30 a first application program executing on a first device 
which is interfaced to a Local Area Network (10) to 
asecond application program executing on a second 
device which is interfaced to the Local Area Network 
(10), the method comprising the steps of: 

35 

receiving a protocol independent data packet 
from the first application program, together with 
data identifying the first application program and 
a destination ID identifying the second applica- 

40 tion program; 

determining which protocols are available for 
use on the Local Area Network (1 0); and 
assigning a respective access line (281, 282, 
283) to each of the protocols available for use 

45 on the Local Area Network, 

said method being characterised by the steps 
of: 

selecting, from the available protocols, the 
50 protocol assigned to the access line having 

the least traffic; 

determining protocol specific information 
which includes a type of protocol header 
and address information in the header cor- 
55 responding to data identifying the first ap- 

plication program and the protocol selected 
in said selecting step; 
forming a transmission packet including the 
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data packet, the destination ID, and the de- 
termined protocol specific information; and 
transmitting the transmission packet to the 
second application program via the Local 
Area Network (10). 5 

2. A method according to Claim 1 , wherein the protocol 
independent interface program: 

assigns a unique access ID to the first applica- 10 
tion program, and 

creates mapping information having a one-to- 
one correspondence between each access ID/ 
access line pair (90) and a block of protocol spe- 
cific information, and wherein said determining 15 
step comprises retrieving a block of protocol 
specific information from the mapping informa- 
tion based on the access ID of the first applica- 
tion program and the access line (281 , 282, 283) 
corresponding to the protocol selected in said 20 
selecting step. 

3. A method according to Claim 1 or 2, wherein the 
second device is a network interface device (7.20) 
which interfaces between a peripheral (1 35) and the 25 
Local Area Network (1 0) and which executes a serv- 
ice routine, wherein said method further comprises 

the step of transmitting data packets including data 
to be serviced by the service routine. 



Patentanspruche 

1. Verfahren zum Zufuhren eines Datenpakets, das 
von einem ersten Anwendungsprogramm empfan- 35 
gen wird, das auf einer ersten Vorrichtung lauft, die 
eine Schnittstelle zu einem lokalen Bereichsnetz- 
werk (1 0) aufweist, zu einem zweiten Anwendungs- 
programm, das auf einer zweiten Vorrichtung lauft, 
die eine Schnittstelle zu dem lokalen Bereichsnetz- 40 
werk (1 0) aufweist, wobei das Verfahren die Schritte 
umfasst: 

Empfangen eines protokollunabhangigen Da- 
tenpakets von dem ersten Anwendungspro- 45 
gramm zusammen mit Daten, die das erste An- 
wendungsprogramm identifizieren, und einer 
Ziel-ID, die das zweite Anwendungsprogramm 
identifiziert, 

Bestimmen, welche Protokolle in dem lokalen 50 
Bereichsnetzwerk(1 0)zurVerwendung zur Ver- 
fugung stehen, und 

Zuweisen einer jeweiligen Zugriffsleitung (281, 
282, 283) zu jedem der Protokolle, die in dem 
lokalen Bereichsnetzwerk (10) zur Verwendung 55 
zur Verfugung stehen, 

wobei das Verfahren gekennzeichnet ist durch die 



Schritte: 

Auswahlen, aus den zur Verfugung stehenden 
Protokollen, des Protokolls, das der den gering- 
sten Verkehr aufweisenden Zugriffsleitung zu- 
gewiesen ist, 

Bestimmen von protokollspezifischen Informa- 
tionen, die eine Art eines Protokoll-Headers und 
Adressinformationen in dem Header enthalten, 
die Daten entsprechen, die das erste Anwen- 
dungsprogramm und das in dem Auswahlschritt 
ausgewahlte Protokoll identifizieren, 
Bilden eines Ubertragungspakets, das das Da- 
tenpaket, die Ziel-ID und die bestimmten proto- 
kollspezifischen Informationen enthalt, und 
Ubertragen des Ubertragungspakets uber das 
lokale Bereichsnetzwerk (10) zu dem zweiten 
Anwendungsprogramm. 

2. Verfahren gemaB Anspruch 1, wobei das protokol- 
lunabhangige Schnittstellenprogramm: 

dem ersten Anwendungsprogramm eine ein- 
deutige Zugriffs-ID zuweist, und 
Abbildungsinformationen erstellt, die eine Eins- 
zu-Eins-Entsprechung zwischen jeder/jedem 
Zugriffs-ID/Zugriffsleitungspaar (90) und einem 
Block von protokollspezifischen Informationen 
aufweisen, und wobei der Bestimmungsschritt 
ein Ermitteln eines Blocks von protokollspezifi- 
schen Informationen aus den Abbildungsinfor- 
mationen auf der Grundlage der Zugriffs-ID des 
ersten Anwendungsprogramms und der Zu- 
griffsleitung (281, 282, 283), die dem in dem 
Auswahlschritt ausgewahlten Protokoll ent- 
spricht, umfasst. 

3. Verfahren gemaG Anspruch 1 oder2, wobei diezwei- 
te Vorrichtung eine Netzwerkschnittstellenvorrich- 
tung (120) ist, die eine Schnittstelle zwischen einer 
Peripherie (135) und dem lokalen Bereichsnetzwerk 
(1 0) bildet, und die eine Dienstroutine ausfuhrt, wo- 
bei das Verfahren fernerden Schrittdes Ubertragens 
von Datenpaketen, die durch die Dienstroutine zu 
bedienende Daten enthalten, umfasst. 



R even di cat ions 

1 . Procede pour delivrer un paquet de donnees recues 
d'un premier programme d'application s'executant 
sur un premier dispositif qui est en interface avec un 
reseau local (10) a un second programme d'appli- 
cation s'executant sur un second dispositif qui est 
en interface avec le reseau local (10), le procede 
comprenant les etapes qui consistent : 

a recevoir un paquet de donnees independant 
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du protocole depuis le premier programme d'ap- 
plication, en meme temps que des donnees 
identifiant le premier programme d'application 
etune I Dde destination identifiant le second pro- 
gramme d'application ; 5 
a determiner les protocoles qui sontdisponibles 
pour une utilisation sur le reseau local (10) ; et 
a affecter une ligne d'acces respective (281, 
282, 283) a chacun des protocoles disponibles 
pour une utilisation sur le reseau local, 10 
ledit procede etant caracterise par les etapes 
qui consistent : 

a selectionner, parmi les protocoles dispo- 
nibles, le protocole affecte a la ligne d'acces 15 
ayant le moindre trafic ; 
a determiner une information specifique de 
protocole qui comprend un type d'en-tete 
de protocole et une information d'adresse 
dans I'en-tete correspondant a des don- 20 
nees identifiant le premier programme d'ap- 
plication et le protocole selectionne dans la- 
dite etape de selection ; 
a former un paquet d'emission comprenant 
le paquet de donnees, I'l D de destination et 25 
I'information specifique de protocole 
determinee ; et 

a transmettre le paquet d'emission au se- 
cond programme d'application:en passant 
par le reseau local (10). so 

2. Procede selon la revendication 1 , dans lequel le pro- 
gramme d'interface independant du protocole : 

affecte un ID d'acces unique au premier pro- 35 
gramme d'application, et 
cree une information d'application ayant une 
correspondance biunivoque entre chaque ID 
d'acces/paire de lignes d'acces (90) et un bloc 
d'information specifique de protocole, et dans 40 
lequel ladite etape de determination comprend 
la recuperation d'un bloc d'information specifi- 
que de protocole a partir de I'information d'ap- 
plication sur la base de I'l D d'acces du premier 
programme d'application et de la ligne d'acces 45 
(281 , 282, 283) correspondant au protocole se- 
lectionne dans ladite etape de selection. 

3. Procede selon la revendication 1 ou 2, dans lequel 

le second dispositif est un dispositif (1 20) d'interface 50 
de reseau qui etablit une interface entre un periphe- 
rique (135) et le reseau local (10) et qui execute un 
sous-programme de service, dans lequel ledit pro- 
cede comprend en outre I'etape d'emission de pa- 
quets de donnees comprenant des donnees devant 55 
etre desservies par le sous-programme de service. 
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